Set top network protocol

ABSTRACT

A method of and apparatus for efficiently communicating between a provider of video on demand services and a cable television subscriber. The communication is implemented using a message protocol specifically optimized to communicate between a multimedia application server and a set top subscriber box. The message format includes unique identifiers for addressing and synchronization to permit the multimedia application server to manage the communication process.

CROSS REFERENCE TO CO-PENDING APPLICATIONS

This application is related to commonly assigned and co-pending U.S.patent application Ser. No. 09/304,907, filed May 4, 1999 and entitled“Video on Demand Transaction Server”; U.S. patent application Ser. No.09/304,906, filed May 4, 1999, and entitled “Video Server”; all of whichare incorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to digital data transmission ofvideo information and more particularly to the delivery of user selectedvideo information to subscribing users.

2. Description of the Prior Art

The mass distribution of video programming signals (i.e., television)was originally accomplished primarily by the broadcasting of a very highfrequency (i.e., VHF) carrier containing an amplitude modulated videosignal and a frequency modulated audio signal. Through the addition ofmore broadcasting transmitters, a modest number of different programmingsignals could be simultaneously distributed to a large number ofpotential users with a modest capital commitment. Using this technique,the capital commitment increases almost linearly with number ofdifferent programming channels within the limits of the availablespectrum space for separate and independent carriers.

Within a couple of decades, most of the scarce VHF spectrum space hadbeen committed, and increasing demand for additional programmingchannels resulted in the allocation of spectrum space in the ultra-highfrequency (i.e., UHF) region. Whereas virtually all receivers became UHFcompatible, as a matter of policy, and UHF channels were assigned torequesters, it was appreciated that there were no economies of scalethrough the addition of more broadcast programming channels.

The cable television channel era was the result, wherein a capitalcommitment was required to wire each user home within a service area. Asa result, about one hundred separate programming channels became readilyavailable at a lesser cost than providing the same number of channelsusing conventional broadcast means. Initially, cable television wassimply an analog system in which low power modulated carriers weretransferred over a coaxial cable rather than being broadcast into theether at substantially higher power levels. The cost saving was realizedbecause the broadcasting was accomplished at substantially lower power.

With approximately one hundred different programming channels, it istypical to charge cable service user fees in accordance with a hierarchyof programming channels. The least expensive channels tend to be thepreexisting broadcast channels and those cable channels supportedprimarily by advertisers which are intended for the most generalaudiences. The subscriber fees to access other channels increase as theprogramming becomes more specialized, advertising revenue becomes lesslikely to pay the programming costs, and the programming materials tendto have substantial economic value through other distribution channels.The so-called “premium channels” which show current and/or near currentmovies without advertising are typical of the higher cost programmingoptions.

Most commercial cable television providers package the variousprogramming channels into programming channel groups with differentprices such that a given user can select a suitable programming packageand pay the equivalent fee. Typically, a cable provider box, whichcouples the user television receiver to the coaxial cable source, iscontrolled by the cable television provider to give access to a givenuser to only those channels for which the appropriate subscriber fee hasbeen paid.

The most expensive cable television channels currently available are“pay-per-view” or PPV. With the PPV concept, a given user can subscribeto a given programming channel for a single individual program of up toseveral hours for a separate subscriber fee. Typically, PPV channelsprovide sporting events and almost current movies.

Perhaps the major disadvantage of the PPV concept as currentlyimplemented, is that the programming is provided in the “broadcast”mode. That means that the programming begins and runs on a predefinedschedule. As a result, programming is missed if the user receives atelephone call, for example, during the viewing. Furthermore, itordinarily requires the user to allocate viewing time to coincide withthe predefined schedule. To overcome this disadvantage, many users rentvideo programs as video cassette recordings (i.e., VCR) from commercialstores which provide such a rental service. This permits the viewer towatch the program in accordance with her/his own schedule, stop theprogram during interruptions, and replay portions of the program whichmay not be readily understood. The primary disadvantage of the VCRrental approach is the need to physically go to the rental store toobtain the program and return to the rental store to return therecording.

With the capital commitment for cable television in place, their appearto be substantial new uses for the basic coaxial pathway. Such usesinclude, telephone, computer modem, facsimile, and video conferencing.To properly coordinate such diverse information transmission activities,attention is being directed to digital transmission schemes whichprovide for easier management of the distribution resources. U.S. Pat.No. 5,570,355, issued to Dail et al., discusses the handling of a numberof diverse information transmissions within a single system. U.S. Pat.No. 5,673,265, issued to Gupta et al., U.S. Pat. No. 5,754,773, issuedto Ozden et al., and U.S. Pat. No. 5,799,017, issued to Gupta et al.,all discuss multi-media distribution systems. U.S. Pat. No. 5,555,244,issued to Gupta et al., is directed to multimedia distribution toresidential users.

The digitization of video results in a great deal of data which must betransferred at a high rate to yield acceptable performance andresolution. By current standards, 3 mbits/sec. is considered to be avery acceptable rate. Such high data rates require systems which canprovide high data rate transmission. U.S. Pat. No. 5,724,543, issued toOzden et al., U.S. Pat. No. 5,699,362, issued to Makam, and U.S. Pat.No. 5,826,110, issued to Ozden et al., all concern themselves with highdata rate retrieval and transmission. U.S. Pat. No. 5,675,573, issued toKarol et al., discusses the management of high data rate bandwidths.

In addition to retrieval and transmission of the required high datarates, there is also the need to provide high speed switching forswitching as between data sources and destinations. U.S. Pat. No.5,751,704, issued to Kostic et al., and U.S. Pat. No. 5,740,176, issuedto Gupta et al., discuss high speed digital switching systems.

Whether it is data storage and retrieval, data transmission, or dataswitching, the fundamental technological problem associated with digitalvideo results from the sheer volume of digitized video data and thetremendous rate at which it must be provided to the ultimate user forsatisfactory performance. One technique for reduction of the volumeproblem is in reducing the resolution (and hence the volume of data) forthose applications for which such reduction is acceptable. U.S. Pat. No.5,623,308 and U.S. Pat. No. 5,691,768, both issued to Civanlar et al.,directly address the handling of multiple resolution digitized videosignals within a single system.

Notwithstanding attempts to reduce the resolutions to the lowestacceptable levels, the total data volume of any commercially usefulsystem will remain high. The most common way to treat extremely highdata volumes is through data compression. U.S. Pat. No. 5,710,829,issued to Chen et al., U.S. Pat. No. 5,742,343, issued to Haskell etal., and U.S. Pat. No. 5,619,256, issued to Haskell et al., areconcerned with digital compression techniques. Specific attention tocompression of digitized video is found in U.S. Pat. No. 5,764,803,issued to Jacquin et al. Compression of 3-dimensional images is treatedby U.S. Pat. No. 5,612,735, issued to Haskell et al.

The evolving techniques of digitized video transmission have resulted ina transmission standard, called Asynchronous Transfer Mode (ATM). U.S.Pat. No. 5,668,841, issued to Haskell et al., describes datatransmission using the ATM standard. An ATM converter is discussed inU.S. Pat. No. 5,809,022, issued to Byers et al. U.S. Pat. No. 5,724,349,issued to Cloonan et al., suggests an approach to packet switchingwithin an ATM system. An ATM architecture is discussed in U.S. Pat. No.5,781,320, issued to Byers. Interfacing to ATM systems is addressed inU.S. Pat. No. 5,842,111, issued to Byers.

A solution to the PPV problems noted above utilizing digitized video hasbeen termed, Video on Demand (or VOD). In a VOD system, digitized videoprogramming is made available to individual cable television subscribersin response to specific requests made by the user. U.S. Pat. No.5,867,155, issued to Williams, describes the use of VOD for a veryspecialized application. Sea Change, International, has proposed a VODapproach for cable television subscribers. U.S. Pat. No. 5,583,561,issued to Baker et al., assigned to the assignee of the presentinvention and incorporated herein by reference, discloses and teaches acomplete, modern VOD system employing a centralized architectureutilizing an enterprise server developed by Unisys Corporation.

To fully utilize VOD for commercially useful subscriber levels,substantial administrative message traffic is required between thesubscribers and the central controlling site(s). For current PPV, thistypically takes the form of telephone communication with the subscriber.This is acceptable for PPV only because the total programming selectionsand timing are so limited. However, VOD on demand so increases theoptions available to the subscriber, such manual attention isimpractical.

SUMMARY OF THE INVENTION

The present invention overcomes many of the disadvantages found withinthe prior art by providing a video on demand system which separates thetasks of supplying video to subscribers from the tasks associated withmanaging the subscriber interface. The subscriber message interfaces canthus be automated such that most administrative matters are easilyhandled without operator attention. A message protocol is provided whichenables the system to properly sequence and manage the message traffic.

The key to this approach is to provide an architecture in which thenecessary functions are divided into two separate portions. A firsthardware and software subsystem, called a video server, is specificallydedicated to retrieving and transmitting the stream of videoinformation. Virtually no other functions are performed by the videoserver. A second hardware and software subsystem, called the transactionserver, handles virtually all other functions including controlinterface with the subscribers, digitized video data storage, subscriberaccounting, etc. In accordance with the present invention, thetransaction server automatically manages message traffic with thesubscribers using the preferred protocol.

The video server has two primary design criteria. First, it must behighly optimized to handle the extremely high input/output data rates.In essence, this is the sole function of the video server, andtherefore, the design of the video server hardware and software are mostdirected towards this characteristic. Because the role of the videosubsystem is simplified and single dimensional, video subsystemsutilizing current technology can be produced at a surprisingly low cost.

The second major design criterion of the video server subsystem involvesmodularity. The addition of active subscribers, each viewing individualvideo programs (or the same program at different times), tends toincrease the total input/output load of the video server subsystemlinearly. Therefore, there is great economic incentive to design thevideo server subsystem in such a manner that the hardware resources toimplement the video subsystem may be linearly increased in relativelysmall (and inexpensive) increments. In the preferred mode of the presentinvention, the video server subsystem consists of one or moreinput/output data rate optimized, industry compatible computersoperating under a readily available, commercial operating system, suchas Windows NT. Using 3 mbits/second per video stream as a standard, eachsuch device can effectively service thousands of different andindependent video streams. Within each video server, storage can beadded to handle more video programs and communication interfaces can beadded to provide more video streams. Therefore, the same designarchitecture and components are suitable for a wide range of systemsizes, and the capital cost to the video programming supplier can bereadily determined as further subscribers are added to the system.

Unlike the video server subsystem which is optimized to provide a lowcost, highly modular approach to a single function, the transactionserver is optimized to provide a low cost approach to a wide and highlyexpandable variety of functions. In fact, all of the functions of thevideo on demand system, except for the video streaming functionperformed by the video server, are accomplished by the transactionserver. Typical tasks include: transactional interface with thesubscribers, subscriber fee accounting, requested program storage, videoserver subsystem control, receiving video from a satellite and storingit in an archive, etc. Thus, the ideal hardware/software platform forimplementation of the transaction server is a readily expandable, highlyflexible, high availability, highly recoverable, realtime orientedmainframe system. In the preferred mode of the present invention, theUnisys 2200 is used to host the transaction server.

In accordance with the present invention, a subscribing user transfers aprogramming request to the transaction server. The transaction servermakes the required subscriber accounting entry and notifies thecorresponding preloaded video server platform of the new subscriberrequest. If the asset is not preloaded, in addition to the subscriberaccounting, the transaction server must access the request video programand spool it for the video server. Depending upon the rate of use of therequested video program, the data might be stored in memory (for highvolume use), on a disk or other mass storage device (for medium volumeuse), or in some other medium (for low volume use).

In the preferred mode of the present invention, the user is permitted topause, reverse, or fast forward the requested video program thoughcommands entered from the set top subscriber box. These functions areintended to appear similar to normal VCR commands to the user. Thesecommands are sent to the transaction server which utilizes them tocontrol the corresponding video stream output of the video serversubsystem. Thus the user is provided with all of the advantages of VCRrental without the need to physically transport the medium (i.e.,cassette tape) back and forth between the rental store and the usersite.

In view of the power and flexibility of the transaction server, otherdiverse but somewhat related functions may be provided. For example, auser might order a pizza delivery via the set top subscriber box totransaction server interface, or the user might access the internet,e-mail, or faxes via the transaction server. If this interface isimplemented over a readily available, publically accessible, network,such as the internet, many additional functions are possible.

As can be readily appreciated, the volume of message traffic between thesubscribers and the transaction server can become substantial in orderto implement these functions. Furthermore, it is necessary for thetransaction server to manage these message, because the set topsubscriber box at the subscriber site is typically a rather “dumb”device having limited or no programmability. The preferred embodiment ofthe present invention employs the basic UDP protocol for data transfersbetween the set top subscriber box and the transaction server. However,in order to properly manage the large number of messages, each is taggedwith a sequence number and set top subscriber box address. Thesemessages also contain a function code which identifies the basic contentof the message and indicates whether a particular message needs to beacknowledged.

BRIEF DESCRIPTION OF THE DRAWINGS

Other objects of the present invention and many of the attendantadvantages of the present invention will be readily appreciated as thesame becomes better understood by reference to the following detaileddescription when considered in connection with the accompanyingdrawings, in which like reference numerals designate like partsthroughout the figures thereof and wherein:

FIG. 1 is a schematic diagram showing the operation of the overall videoon demand system of the present invention;

FIG. 2 is a schematic diagram showing spooling of the video programmingdata from typical mass storage devices;

FIG. 3 is a schematic diagram showing the generation of a video streamfrom spooled data within a memory subsystem;

FIG. 4 is a schematic diagram showing video streaming as synchronized onone minute boundaries;

FIG. 5 is a schematic diagram showing operation of a video serverplatform;

FIG. 6 is a schematic diagram showing video streaming of multipleprograms from a single video server platform;

FIG. 7 is a schematic diagram showing video streaming from videoprogramming data spooled on disk drive mass storage units;

FIG. 8 is a schematic diagram showing video streaming from videoprogramming data stored on both disk drive mass storage units and memorysubsystems;

FIG. 9 is a block diagram of a maximum configuration video server;

FIG. 10 is a detailed diagram of the operation of the transaction serverof the preferred mode of the present invention;

FIG. 11 is a system diagram of the VOD network showing the major dataand message paths;

FIG. 12 is a system diagram showing a high reliability system employingredundancy;

FIG. 13 is a system diagram showing major message paths;

FIG. 14 is a diagram showing the basic message format; and

FIG. 15 is a table of the defined function codes.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 is a schematic diagram 10 showing the overall video on demandsystem of the present invention. A subscribing user (not shown) ispositioned adjacent standard television receiver 34. Through thistelevision receiver, the user is capable of viewing video programmingmaterial transferred to his location via coaxial cable 30 from network26 in the fashion currently known in the cable television industry. Theinterface between coaxial cable 30 and standard television receiver 34is provided by set top subscriber box 32, which provides the conversionbetween MPEG-2 digitized video format and the analog video signalrequired by television receiver 34.

In many respects, set top subscriber box 32 is similar to the set topsubscriber boxes utilized with existing cable television systems withthe slight functional differences described in more detail below. Thebasic reason for these slight differences is to permit a subscribinguser to communicate with transaction server 12 in a two directionalmanner. Not only does set top subscriber box 32 receive videoprogramming data via coaxial cable 30 and present it to televisionreceiver 34, but set top subscriber box 32 is capable of transferringuser requests via coaxial cable 30 and network 26 to transaction server12 via path 28. The most important requests in accordance with thepresent invention are those which initiate and control theindividualized video on demand programming.

When the user is interested in viewing a particular video program, arequest is made from set top subscriber box 32 and transferred totransaction server 12 via coaxial cable 30, network 26, and path 28.Transaction server 12, a Unisys 2200 system in the preferred embodiment,is provided access to video programming information from satellitereceiver 14, from analog video storage 16 and digital mass storage 18.In each instance, the video programming data is either received indigital form or converted to digital form. According to the preferredembodiment of the present invention, the MPEG-2 standardized format isutilized.

Whenever a request is received, transaction server 12 checks varioussecurity parameters, makes appropriate subscriber billing entries, andgenerally performs all of the necessary administrative functions asdescribed below in greater detail. Additionally, transaction server 12stores digital video data for transmission by the video server assignedto the requesting subscriber. One of video server platforms 20, 22 . . ., or 24 is assigned the task by transaction server 12 and the storeddigital video data is supplied via the digital data bus shown. In thepreferred mode of the present invention, each video server platform is aseparate industry compatible, Windows NT based, computer platform. Oncetransferred to the selected video server, the requested videoprogramming is transmitted via network 26 and coaxial cable 30 to settop subscriber box 32 and television receiver 34.

FIG. 2 is a schematic diagram showing the spooling of data from digitaldisk mass storage devices. For the preferred mode of the presentinvention, the digitized video programming data is stored in MPEG-2format. In the spooling process, the MPEG-2 organized and placed intomemory as a programming file 55. To produce commercially acceptablevideo, 3 mbits/second is required. That means that a two hour videoprogram requires the about 2.7 billion bytes of data storage. Because ofcost considerations, many of the programs having low and moderate usagewill best be stored on mass storage disk until requested

Individual storage disks 48, 50, . . . , and 52 each store a number ofvideo programs in MPEG-2 format. As requested, this data is transferredvia storage bus 46 through disk control 42 through I/O bus 38 and placedin memory as program file 55 via path 40. A software program spools thedata to the ATM interface 54 at the required speed.

FIG. 3 is a schematic diagram showing spooling of high volume digitizedvideo program. For those programs having a high user demand, it is muchmore efficient to spool the program files from random access memoryrather than mass storage disk systems. In this context, high volumemeans a high probability that the given program will be in use duringhigh service volume periods. That means that there will need to berandom access storage allocated to the storage of that given programduring peak memory demand. As a result, the system should simplyallocate random access storage to that given program. Very popular,recent movies are typical of such high volume programs.

If a program is a high volume program, it is preferably stored inauxiliary memory 56. Upon request, software residing in memory 36directs the storing of data from auxiliary memory 56 and transferring itvia path 40 and I/O bus 38 to ATM interface 54. It should be noted thatthis is significantly more efficient than the storing operation shown inFIG. 2, since the video data only needs to be read out of memory insteadof having to be loaded from disk each time the data is used.Furthermore, there is no additional cost if a program is of sufficientlyhigh volume that the required random access memory must be allocated tothe program anyway.

FIG. 4 is a schematic diagram 58 showing the synchronization of a givenvideo program around one minute time slots. In concept, the presentinvention provides subscribers with video on demand. However, as apractical matter, by synchronizing multiple users around one minute timeslots, the maximum number of transmissions to all users of the givenvideo program cannot exceed 60 per hour of programming and 120 for a twohour standard video program. That means that for a given high volumeprogram (which may be requested by hundreds or even thousands within thelength of time to view the program) each requester is assigned to anappropriate time slot.

First time slot 60 provides the first minute of video programming to oneor more requesters. During one minute time slot 62, the initialrequesters receive the second minute of programming, and one or morerequesters may be starting with the first minute of programming. At thenth time slot 64, the initial requesters are viewing the nth minute ofprogramming, the second group of requesters is viewing the n−1 minute ofprogramming, and the nth group of requesters is viewing the first minuteof programming. At final time slot 66, the initial requesters areviewing the final minute of programming, the second group of requestersis viewing the second to last minute of programming, and a new group ofrequesters is viewing the initial minute of programming.

The reduction in total data requirements utilizing these one minute timeslots is substantial. Commonly assigned U.S. Pat. No. 5,583,561, issuedto Baker et al., incorporated herein by reference, discusses thisfeature in greater detail. The total delay to a requester is no morethan one minute and will average one half minute, making the processperfectly acceptable and barely noticeable to the subscribers.

FIG. 5 is a schematic diagram of a single industry compatible, WindowsNT based video server platform. The video server subsystem is composedof a number of separate and largely independent video server platforms.Each is configured to have a maximum memory configuration and maximumI/O configuration. Digitized video programming data in the MPEG-2 formatare moved from transaction server 68 via interconnect 70 into theassigned video server platform. Program 74 and program 72 are shown.These programs are place onto network 78 under control of transmissioncontrol software 80 for transfer to the requesting subscriber(s). For agiven program being sent to a single user, transmission control software80 simply retrieves the video data from memory in a sequential fashionat 3 mbits/second and places it on network 78.

FIG. 6 is a schematic diagram showing transfer of high volume program 82into the video server platform of FIG. 5. The transfer is performed bythe transaction server as discussed above. The transferred data istransferred to the video server platform via I/O bus 84 Up to tenprograms can be stored and streamed from a single video server Forsimplicity, only one video server is shown. For a view of multiple videoservers within a system, refer to FIG. 1. All other referenced elementsare as previously described.

FIG. 7 is a schematic diagram showing the spooling of low to moderatevolume digitized video program data. For lower volume programs, storageon disk storage mass memory may be appropriate. A low volume videoprogram is one in which it is highly unlikely that more than one requestis received during the runtime of the video program. Therefore, theservicing of the request is most probably an index sequential task forretrieving the data and transmitting it to the user. This is readilydistinguishable from the high volume video programs for whichtransmissions within multiple and perhaps many of the one minute timeslots is expected (see also FIG. 4). These programs are spooled to thevideo server platform as shown. The remaining referenced elements are aspreviously described.

FIG. 8 is a schematic diagram showing transfer of low and high volumevideo programs to the same video server platform. All referencedelements are as previously described.

FIG. 9 is a block diagram 84 of the maximum configuration of thetransaction server of the preferred mode of the present invention. Inthis preferred mode, the video server is implemented using a currentmodel Unisys mainframe system. In accordance with this product, thesystem is expandable from a single processor, single main memory, andsingle I/O controller to the maximum system shown.

Instruction processors 102, 104, 106, 108, 110, 112, 114, and 116communicate with main memories 86, 88, 90, and 92 via crossbarinterconnects 94, 96, 98, and 100. Each instruction processor may becoupled with up to four third-level caches, as shown. DirectInput/Output bridges 118, 120, 122, 124, 126, 128, 130, and 132 eachhandle video output functions. Each of the direct Input/Output bridgesmay be partitioned into separate partitions as shown. Additionaldescription of partitioning may be found in U.S. patent application Ser.No. 08/779,472, filed Jan. 7, 1997, commonly assigned to the presentinvention and incorporated herein by reference.

FIG. 10 is a detailed functional diagram 134 of the transaction server.Communication with set top subscriber box 32 (see also FIG. 1) ismanaged by set top management module 142. Initial requests are selectedby the user and honored through utilization of menu transaction module140. After initiation of the servicing of a given request, control ofthe matter is given to session manager 138 for completion. Any and allcommunication with the transaction server are monitored by securitymodule 148. Administration module 136 provides overall control of thetransaction server.

The transaction server may be utilized to interface with the internet.The selected hardware and software system selected for the preferredmode provide internet server facilities in a commercially usable form.Video server session management module 146 provides the detailedfunctions (e.g., spooling of digital video programming) associated withthe primary video on demand service. These control functions aredirectly interfaced to the video server subsystem via video serverinterface 150.

Event logging module 154 journals the functions performed. This log ismade available to digital network control services 152. Media directoryservices and asset management module 162 provides long term control andasset management. Historical storage of these data is performed by assetstorage management and asset capture.

In performing the actual video on demand service, the appropriaterequested digitized video program is accessed from databases 160. It isspooled by asset delivery, video streaming module 158. The transfer ismade via video server interface 156 (see also FIG. 1).

FIG. 11 is a diagram 170 of the overall VOD system with particularemphasis upon the data and message transfer paths. MultimediaApplication Server (MAS) 172 accesses Resource and Subscriber Database186 via interface 174 and Asset Database 188 via interface 176.Similarly, Asset Archive Storage 190 is accessed via interface 180.

Multimedia Application Server 172 interfaces with all other major systemelements via path 182. ATM channel adapter 192 provides the link usingthe ATM protocol to interface 194 and ATM network 200.

ATM interfaces include path 196 to router 198 which communicates withworkstations 204 via radio frequency path 202. Router 212, coupled viapath 208, also interfaces to Local Area Network (LAN) and toworkstations 218 and 220 via stubs 214 and 216, respectively. ATM 200 isalso coupled directly to individual set top 228 via path 210 and to VODA222 for streaming video along path 224 to QAM modulator 230, whichsupplies video to set top 228.

FIG. 12 is a diagram showing a highly reliable video on demand systememploying redundancy. The high reliability is achieved by havingMultimedia Application Server (MAS) 232 completely duplicated asMultimedia Application Server 266. During peak loading, both can providesubscriber services. During periods of lesser loading, one or the othermay be removed from service due to failure, maintenance, etc. XPC fileaccelerator 258 couples these two duplicate entities. Each MultimediaApplication Server (i.e., 232 and 266) are redundantly coupled toResource and Subscriber Database 260, Asset Database 262, and AssetArchive Storage 264.

Within Multimedia Application Server 232 (and corresponding MAS 266) arefound the Multimedia Application Server core software 240 (andcorresponding core software 274) which communicates via middleware 242(and middleware 276). Communication is with Relational Database 234(268) via path 238 (272), and Message Retention Services 256 (280) viapath 254 (278). CPCOMM 252 (282) and ATP 250 (286) communicate directlywith Video Server Frame and Stream Spooling 236 (270) via path 248(284). Similarly, communication is had maintained with FTP 246 (290) viapath 244 (288).

FIG. 13 is diagram 300 which conceptually shows the major message pathsin a Sonnet Ring configured system. Multimedia Application Server 310directly communicates with system components: Asset Storage 308, AssetManagement 306, ISP Connection 302 and Filling System 304.

Multimedia Application Server 310 receives messages directly from settop subscriber box 322 via path 312. It transfers messages to set topsubscriber box 322 through path 314 to Sonnet Ring 316 to Hub 318 andthen through cable 320. This path also provides the video for display ontelevision receiver 324.

FIG. 14 is a diagram 326 of the message format used to communicatebetween Multimedia Application Server 310 and set top subscriber box 322(see also FIG. 13). Field 328 contains a four byte integer giving theversion level. The current version is 2.

Field 330 is designated Set Top Command and Control Protocol (STCCPL).It is a four byte integer which specifies the length in bytes ofvariable length field 342. Field 332 is a four byte integer whichprovides the sequence number. This sequence number permits theMultimedia Application Server and set top subscriber box to synchronizemessage traffic by establishing the order in which messages have beengenerated. The sequence number is created by incrementing the sequencenumber of the previous message. For those messages which must beacknowledged (see below), the sequence number permits coordinatingmessages and acknowledgments.

The basic function code is specified in the four byte integer of field334. These function codes are defined in more detail below. TheMultimedia Application Server defines a unique four byte integer whichis inserted into field 336. This is defined as the Connection ID. Field338 provides for the entry of eight one byte integers. In the preferredembodiment, only the first five integers are used to uniquely addressone set top subscriber box within a network. The remaining three onebyte integers are left blank.

Field 340 is the packet type. It is specified as a four byte integer.The packet type is undefined for messages sent from a set top subscriberbox to the Multimedia Application Server. For every message theMultimedia Application Server receives, it sends a response back to theset top subscriber box containing the STCCP output. This packet type isgiven the value of 1. An unsolicited administrative message sent fromthe Multimedia Application Server to the set top subscriber box whichdoes not require an acknowledgment is defined as packet type 2. Asimilar message requiring an acknowledgment is defined as packet type 3.

Variable length field 342 may be from 0 to 952 bytes in length. Thelength is specified by field 330. This provides great flexibility increating new and unique messages for specific occasions.

FIG. 15 is a table showing the definition of the basic function codes tobe entered into field 334 (see also FIG. 14). The function code of 1 isused to indicate to the Multimedia Application Server that a particularset top subscriber box has been switched on.

Messages sent from the Multimedia Application Server to one or more settop subscriber boxes are assigned the function code of 2. A messagehaving a function code of 3 notifies the Multimedia Application Serverthat the corresponding set top subscriber box has been powered down.

The set top subscriber box acknowledges messages from the MultimediaApplication Server using a function code of 4. Reinitialization of a settop subscriber box is identified by a function code of 5.

Having thus describe the preferred embodiments in detail, those of skillin the art will be readily able to use the teachings found herein tomake and use yet other embodiments within the scope of the claimsappended hereto.

1. An apparatus for delivering video on demand programming from amultimedia application server having a first hardware and softwarearchitecture optimized to provide a low cost approach to a wide andhighly expandable variety of functions to a set top subscriber boxcomprising: a. a temporary memory responsively coupled to saidmultimedia application server into which said multimedia applicationserver spools a selected video program; b. a plurality of video serverseach having a second hardware and software architecture optimized tohandle high input/output rates which is different from said firsthardware architecture responsively coupled to said temporary memorywherein one of said plurality of video servers selected by saidmultimedia application server streams said video program from saidtemporary memory; c. a network responsively coupled to said video serverwhich delivers said video program as streamed by said video server tosaid set top subscriber box; d. a separate administrative message pathresponsively coupled to said set top subscriber box and said multimediaapplication server; and e. a message generated by said set topsubscriber box and transferred from said set top subscriber box to saidmultimedia application server via said separate administrative messagepath, wherein said message further comprises a message length fieldlocated within said message which indicates a length for said message,and a message sequence number which identifies said message within aplurality of messages, f. a response message generated by saidmultimedia application server in response to receipt of said message andtransferred via separate administrative path to said set top subscriberbox.
 2. An apparatus according to claim 1 wherein said message requestsselection of and corresponds to said video program.